Using Integer Programming to Optimize Investments in Security Countermeasures: A Practical Tool for Fixed Budgets

Software engineers and businesses must make the difficult decision of how much of their budget to spend on software security mitigation for the applications and networks on which they depend. In this article, we introduce a novel method of optimizing, using Integer Programming (IP), the combination of security countermeasures to be implemented in order to maximize system security under fixed resources. We describe the steps involved in our approach, and discuss recent results with a case study client. Introduction Software engineers and their customers are continuously faced with a complex and frustrating decision: Given a fixed budget, which combination of vulnerability mitigation actions produces optimal security for a system? In a world with no budgetary or temporal constraints, one could invest in whatever tools or training deemed necessary to safeguard the applications and networks on which customers depend. Engineers could spend arbitrary amounts of time and money patching existing code and take painstaking precaution in writing new software to ensure its security. Of course, the economic reality is that software engineers are pushed to get their product to market as fast as possible, and security is often deemed a distant priority due to budgetary constraints. Fixing the remaining security vulnerabilities post-production can be costly and is wasteful of resources. In this article we describe a novel methodology for quantitatively optimizing the blend of architectural and policy recommendations, in terms of threat mitigation, that engineers can apply to their products in order to maximize their level of security under a fixed budget. The results of our optimization are sometimes surprising and even counter-intuitive: bigger budgets do not always produce greater security, and the optimal combination of corrective actions changes nonlinearly with increasing expenditures. These findings suggest that some form of formal decision support may usefully augment traditional methods, and the apparent success of our case study demonstrates the feasibility of this integer programming approach. The problem we are addressing is nontrivial for several reasons. The first challenge is the ability to obtain plausible, reliable, and quantitative estimates of the cost of fixing security vulnerabilities and the corresponding benefits from averting losses due to a breach. There is a large body of academic literature on eliciting such subjective judgments, particularly for risky outcomes, and we used rather than advanced that knowledge base [4, 11, 12]. The innovation here is not how to elicit those parameter values, but rather what methods are used to move from those judgments to an action plan. The second challenge to prioritizing such corrective actions is their many-to-many relationship with the security problems they solve. If there were a one-to-one relationship between action and vulnerability, one could simply order the security actions in terms of “bang for the buck.” The security mitigation action that solved the most threatening problem would be implemented first, and the remaining actions would then be taken in order of decreasing cost-effectiveness ratio until either time or resource limitations prohibit further steps. However, no such simple ordering is possible when there is a many-to-many relationship. In fact, the decision of which blend of mitigation steps should be pursued is combinatorial, with the number of combinations growing exponentially with the number of potential actions. Thus, considering every combination is prohibitively time-consuming. Fortunately, the problem can be couched as a mathematical optimization problem (specifically, an integer program or IP [13]) and solved at least to a very good approximation of optimality with a range of software packages, including even ubiquitous spreadsheet programs such as Microsoft Excel [7, 8]. The details of this formulation are given in a technical report [6].